Secured inter-processor and virtual device communications system for use in a gaming system

ABSTRACT

The invention comprises an electronically secured inter-processor and virtual device communications system, with an input/output controller board, a multi-drop bus interface to multiple devices, and a parallel interface to an industry standard single board computer. The invention assigns a bus address and virtual identification number to each device and controls communications between the main central processing unit and the devices through a Plug-n-Play protocol.

FIELD OF THE INVENTION

The present invention is directed generally to an electronically securedinter-processor and virtual device communication system used in gamingmachines and is directed more particularly to an electronically securedinter-processor and virtual device communications system with (1) anInput/Output Controller Board (hereinafter referred to as “IOCB”), (2) amulti-drop bus interfacing one or more device modules, (3) a parallelinterface to an industry standard main single board computer(hereinafter referred to as the “SBC”) of the gaming machine and (4) aIOCB-to-device “Plug-N-Play protocol (the “Plug-N-Play Protocol”).

BACKGROUND OF THE INVENTION

Conventional methods of integrating a variety of components in a gamingmachine currently require re-designing, re-wiring and re-programming thegaming machine as each new component is added. As technology advances,newer state-of-the-art devices are being offered to manufacturers ofgaming machines that would greatly enhance the product, butmanufacturers are inhibited, as removing and replacing the old deviceswith new devices, or simply adding the new device requires reprogrammingthe SBC and could require the re-design and/or replacement of the SBC.

The industry standard SBC board, independent of the microprocessor used,has been designed using discrete components with EPROM memory chipscontaining software with an individual bus connected to each device. Asmost of the gaming machines in the market require some sort ofregulatory approval, modifying a previously approved product requires are-submittal to the regulatory agency with the re-submittal emphasisingrecertification of the programming of the new device in the CPU. Withthe software for each device residing in the EPROM, this requiresreverification of the entire program.

Especially for manufacturers with a significant installed base of gamingmachines, retrofitting these machines with a newer device is anexpensive proposition and a logistical nightmare. Utilising a‘Plug-N-Play’ concept, the Invention, through the Input/OutputController Board (IOCB), logically interconnects all the devices in thegaming machine to the SBC. The IOCB's communications to and from eachdevice is based on a network-capable communications protocol, such asPhilips' Inter-Integrated Circuit (I²C) two-wire Serial Interface(hereinafter “PHILIPS I²C”).

As the IOCB logically interconnects the modules or potential modules tothe SBC, the SBC and its EPROM memory chips do not have to bereprogrammed, resigned or replaced. Further, as no device relatedsoftware resides on the SBC or its EPROMS, no new software needs to beresubmitted to any regulatory agency, as no new software is created.Instead each device in the machine incorporates an intelligent boardwith microprocessor (the “Device Board”) which is programmedspecifically to the functions of that device. The Device Board alsocommunicates via the communications protocol, such as PHILIPS I²C, tothe IOCB in a multi-drop configuration. Replacing a device or adding anew device is simply a matter of connecting the communications interface(Clock, Data, Logic Power, System Ground) to the multi-drop businterconnecting all the devices to the IOCB.

The IOCB programming module continuously monitors the communicationsprotocol interface (the PHILIPS I²C line) for device activity and relaysthese actions to and from the SBC. As new devices are added to the link,a specific registration protocol is followed which will allow the deviceto register with the IOCB. If the registering device has followed allthe secured protocols, the specific parameters of the device (devicetype, Serial Number, etc.) are relayed to the SBC.

The SBC has several modules programmed for all possible devices that mayconnect to the machine, such as a Coin In, Coin Out, and Bill Acceptormodules. Even though there may be several types of these devices, theappropriate SBC module simply monitors for coins in, coins out and billsaccepted. The specific hardware and protocol of each connected device islevel converted and formatted by each Device Board to a generic formatrequired by the SBC module.

Accordingly, an object of the invention is an electronically securedinter-processor and virtual device communication system which allowsdevices to be added to, replaced in or changed in a gaming machinewithout any need to reprogram or redesign the SBC of the gaming machine.

A further object of the invention is an electronically securedinter-processor and virtual device communication system which allowsdevices to be added, replaced in, or changed in a gaming machine withouta need to replace the SBC of the gaming machine.

An additional object of the invention is an electronically securedinter-processor and virtual device communication system which allowsdevices to be added to, changed in, or replaced in a gaming machinewithout the need to modify the software residing in the CPU or anydevice so that a resubmittal to an appropriate regulatory body would notbe necessary.

Still another object of the invention is an electronically securedinter-processor and virtual device communication system whichcost-effectively allows devices to be changed in a gaming machine.

Furthermore, an object of the invention is an electronically securedinter-processor and virtual device communication system which allowsdevices to most efficiently be added to, replaced in or changed in agaming machine.

An additional object of the invention is an electronically securedinter-processor and virtual device communication system with a protocolwhich supports dynamic assignment of device addresses.

Still a further object of the invention is an electronically securedinter-processor and virtual device communication system which providesreliable and secure communications among interprocessors.

SUMMARY OF THE INVENTION

These and other objects of the invention, which shall become apparenthereafter, are achieved by providing an electronically securedinter-processor and virtual device communication system, including anIOCB connecting a multitude of peripheral gaming machine devices and theSBC through parallel interface. In an embodiment, the IOCB provides aninterface between the SBC of the gaming machine and the machine'sdevices and is connected to the SBC through a parallel interface. TheIOCB uses a multi-drop communication bus for its connection with thedevices requiring at least four wires for the clock, data, logic power,and system ground protocol. Each device contains its own CPU boardprogrammed for the specific device. When power is first applied to thegaming machine, the IOCB attempts to establish a link with the SBC byplacing a ‘link request’ transaction in the IOCB's transmit queue andcommencing an idle state. The IOCB then remains in an idle state untilthe SBC acknowledges a physical connection. Once the SBC acknowledges aphysical connection, the IOCB sends the ‘link request’ transaction tothe SBC, preferably through the IOCB's Parallel Slave Port (Data) (the“PSP-Data”). When the link is established, the IOCB sends a framedpacket to the SBC containing the Virtual ID and device registrationcommences. Independently of the SBC and the IOCB, each device's CPUattempts to register the device's hardware with the IOCB through themulti-drop bus. As the IOCB registers each device, the IOCB assigns ancommunications protocol address, preferably the PHILIPS I²C address, tothe device and creates a device table entry containing data uniquelyidentifying the device, such as type of device, serial number, and thecommunications protocol address. As each device is registered, the SBCassigns and stores a virtual identification number (the “Virtual ID”).After all devices are registered, the IOCB stores information about eachregistered device and transfers any pertinent packets received from adevice to the SBC.

In a preferred embodiment, the IOCB is the only external deviceinterfacing the SBC with the gaming machine's devices such as DeckButtons and Lamps, Coin In Mechanisms, Coin Out Hoppers, Bill Acceptors,Magnetic-Stripe Card Readers, Keypads, Progressive Display Interfaces,Ticket Printers, Coupon Dispensers, Hard Meters and general Securityswitches in the machine. The IOCB's physical connection to the SBC ispreferably via a parallel interface on the SBC, preferably a PC-104 buswhich is capable of transfer rates up to 8 million bytes per second. Thedata transfer between the IOCB and SBC is interrupt-driven andcontrolled by an 8-bit register.

The IOCB interfaces the listed devices through a Multi-Dropcommunication scheme using a network-capable communications protocol,such as RS-485, USB, current loop, or preferably Philips Corporation'stwo-wire Inter-Integrated Circuit (I²C) serial interface andcorresponding communications protocol (hereinafter “I²C protocol”),which enables speeds up to 400 kbps.

The communications protocol, preferably the I²C protocol, ensuresreliable transmission and reception of data. When transmitting data,only one apparatus, preferably the IOCB, is the ‘master’ which initiatestransfer on the bus and generates the clock signals to permit thattransfer, while the other device(s) acts as the ‘slaves’.

The Philips communication protocol (“I²C Protocol”) operates on top ofPhilip's published industry standard I²C protocol. Additionalinformation on the PHILIPS I²C specification can be obtained from thedocument “The I²C bus and how to use it”, #939839340011, available fromthe Philips Corporation.

The communications protocol, preferably the I²C protocol, constitutesthe physical layer for the invention's IOCB to Device ‘Plug-N-Play’protocol, 5 which is a packet-driven securitized protocol.

The preferably I²C framed ‘Plug-N-Play’ protocol supports dynamicassignment of I²C addresses, facilitates reliable communications betweenI²C devices and the IOCB and provides a secured link for inter-processorcommunications.

A multi-wire Multi-Drop bus, preferably a four-wire multi-drop bus(Clock, Data, Logic Power, System Ground), interconnects all devicesthroughout the machine to the IOCB. Each device is equipped with afirmware-based CPU board which is programmed to the specific parametersand purpose of each device. Each device's CPU board is capable ofcommunicating with the communications protocol, preferably the I²Cprotocol.

Messages are routed to and from the IOCB to the devices using acommunications protocol framed packet, preferably an I²C framed packetcomprised of an I²C address, header, body and footer, as specifiedbelow.

To prevent statistical breakdown of the CRC-16, packets will be limitedto a maximum of 255 bytes inclusive of the I²C Address and Footer.Message bodies larger than 248 bytes must be broken up into multiplecommunications protocol framed packets, preferably I²C framing packets.

When power is first applied to the gaming machine, the IOCB attempts toestablish a link with the SBC by placing a ‘link-request’ transaction inthe IOCB transmit queue, which commences an idle state. The IOCB remainsin this idle state until the SBC acknowledges a physical connection.Upon receiving acknowledgment of the physical connection, the IOCB sendsthis link request transaction to the SBC via preferably the ParallelSlave Port (PSP Data) of the IOCB through a PSP-framed packet containingthe Virtual ID of the device. Once the link is established, deviceregistration begins. Neither the IOCB nor the SBC has knowledge of thedevices integrated in the machine. Each device's CPU will attempt to‘register’ its specific hardware with the IOCB by communication throughthe communications protocol multi-drop bus, preferably a I²C Multi-Dropbus. As each device is registered by the IOCB, the IOCB dynamicallyassigns a communications protocol address (range 9–76 h), preferably anI²C address, to the device and enters the device information into adevice table which stores the device's specific data (type of device,serial number, etc.). As long as power is applied to this device, adevice responds to IOCB requests using this communications protocoladdress, such as an I²C address. The IOCB also assigns Virtual ID(Circuit Number) to the device referencing the device to the SBC. TheSBC uses this Virtual ID to invoke a software driver referencing thisdevice type regardless of its communications protocol, preferably I²C,address. The Virtual ID remains assigned to the device and, should thedevice lose power, upon re-registering, the device may receive adifferent communications protocol, preferably I²C, address but willmaintain the same Virtual ID. This process repeats until all deviceshave been registered.

As each new device is dynamically registered, a table entry in theIOCB's device table is created for that device. As the IOCB iscontinuously polling these registered devices, the IOCB will detectremoval of a device and will send notification to the SBC.

After device registration, utilising a prioritized polling scheme, theIOCB will query each registered device for status. The IOCB eitherreceives a ‘no activity’ packet or a packet containing pertinent datafor that device. If required, the IOCB transfers a valid packet to theSBC via preferably the PSP-Data port.

If a registered device fails to respond to its poll after a fixed numberof retries, the IOCB declares the device ‘inactive’ by sending anappropriate PSP framed transaction to the SBC.

The IOCB communicates with the SBC via a parallel port connected to aPC-104 bus on a SBC. The interrupt-driven data transfer is controlled bya shared 8-bit register which is used as handshaking flags for flowcontrol.

The communications protocol bus is a multi-wire communicationsinterface, preferably a I²C bus with a two-wire serial interfacedeveloped by the Philips Corporation which enables speeds up to 400kbps.

The IOCB will be interrupted by the PSP-Data if the SBC initiates anyPSP framed transactions. If the SBC initiates a transaction, the IOCBwill wrap the PSP framed characters with communications protocol framingcharacters, such as I²C framing characters, sending this data to theappropriate device at that communications protocol address.

In any setting, the IOCB's sole responsibility is to direct secured datatransactions to and from the SBC and to and from the gaming machine'sdevices. The IOCB does not initiate or control any functions of thegaming machine.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention would be better understood from the following DetailedDescription of the Preferred and Alternate Embodiments, with referenceto the accompanying drawings, of which:

FIG. 1 is one embodiment of the invention showing the SBC of the gamingmachine connected to the IOCB and connected to seven devices throughdevice boards in a multi-drop bus configuration.

FIG. 2 is an embodiment of the invention, showing the preferred PC-104bus of the SBC connected through a preferred parallel interface by an8-bit bi-directional bus to two parallel slave ports (PSP-Data andControl, and the 8-bit register) of the IOCB.

FIG. 3 is a preferred embodiment of the invention, showing the IOCBconnected in a multidrop configuration with four wires to five devices.

FIG. 4 is a flow chart showing the transmission of data from the SBC tothe devices through the IOCB.

FIG. 5 is a flowchart showing the transmission of data from the devicesto the SBC through the IOCB.

FIG. 6 is a flowchart depicting the four-level security of theinvention, which ensures the validity of data transfers. and

FIG. 7 is a flowchart depicting the registration of devices by the IOCB.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring to the drawings, wherein like numerals reflect like elementsthroughout the several views, FIG. 1 depicts the SBC (generally 1) ofthe gaming machine, as connected to the Input/Output Controller Board(“IOCB”) (generally 200). The IOCB 200 is connected in a multi-drop busconfiguration 250 to the devices (3A, 3B, 3C, 3D, 3E, 3F, 3G), eachdevice with its own microprocessor inclusive board (respectively, 4A,4B, 4C, 4D, 4E, 4F, 4G). The devices depicted are a coin comparator 3A,a bill validator coupon 3B, a coin out hopper 3C, a magnetic card reader3D, a coupon dispenser 3E, a progressive interface 3F, and a deckbuttons/lamps 3G. Each device (3A through 3G) has its own board (4Athrough 4G) (the “Device Boards”) and is virtually connected to the SBCI and to the other devices through the multi-drop bus configuration 250.

Single Board Computer (SBC):

The SBC 1 is capable of digital storage, contains a microprocessor,preferably a Pentium II, and preferably contains sound and videocapability, wave file capability, networking capability, and modemconnections.

Input/Output Controller Board (IOCB):

The IOCB 200 is a Microprocessor based electronic board featuring amicroprocessor, preferably a PIC 17C756, preferably on-board RandomAccess Memory (RAM), preferably Non-Volatile RAM, preferablytimer/counters, preferably Capture/Compare/PWM modules, preferably two8-bit parallel ports (Parallel Slave Port (PSP) Data 201, PSP Control202), preferably one Serial Communications Interface, preferablytwo-wire Inter-Integrated Circuit (I²C) bus 203, preferablyinternal/external Interrupt sources, preferably a Watchdog Timer,preferably a Brownout detection and preferably Programmablecode-protection. The IOCB 200 has the ability to set up and communicatein the communications protocol standard, to communication with at leastone device, and to perform distributed processing.

Device Microprocessor Board Hardware:

Attached to each device 3A through 3G in the gaming machine is aMicroprocessor based electronic CPU board (the “Device Board.”) 4Athrough 4G. Each board is specifically designed and programmed tointerface with the specific function of its associated device. Thedevices are connected to the IOCB 200 in a multi-drop configuration 250.Each board is capable of communicating in a communications protocol,preferably an Inter-Integrated Circuit (I²C) communications protocol,and contains a microprocessor, preferably a PIC 16C67. Integratedcomponents of the board (size of RAM, high current output drivers, etc.)are application specific. Each board 4A, 4B, 4C, 4D, 4E, 4F, 4G containsa memory component, preferably a 64-bit serialised memory component,which is used as another security check in the design. The unique serialnumber of each component of each Device Board is installed into theboard at time of production and provides a unique identification numberfor each board (the “Board”). The Board ID is used in the packettransmissions to and from the IOCB 200 as another signature verificationin the calculation of the CRC-16.

FIG. 2 depicts the preferred PC-104 port 100 of the SBC 1 connected bypreferably an 8 bit bi-directional bus to preferably the IOCB's PSP-Data201 and PSP-Control 202 port and to the IOCB's 8-bit register.Communication to and from the SBC 1 is accomplished through the IOCB's8-bit PSP Data and PSP-Control port 201, 202 and the SBC's PC-104 bus100 and the bi-directional interrupt driven data transfers utilise ashared 8-bit register 205 which regulates data direction and flowcontrol. Depending on its specific task, the IOCB 200 will set and resetthe handshaking control bits, with the SBC 1 to monitor these statusbits.

Each bit of the 8 bit register 205 preferably is populated as follows:

bit 7 6 5 4 3 2 1 0 RTR RA RTT TA CONNECT 0 ZERO RESET

-   -   Bit 7—Ready To Receive (RTR) 202A preferably indicates, if set,        that the IOCB 200 is ready to receive a data byte. If the SBC 1        has a character to send, it reads this statusbit and if set,        will send the character. If reset, a time-out interval is        initiated and if it expires, the SBC will report an error which        locks up the game.    -   Bit 6—Receive Aborted (RA) 202B preferably indicates, if set,        that the IOCB has detected a communication error while receiving        data. The SBC 1 also monitors bit 6 prior to sending a        character, and if Bit 6 is set, the SBC 1, will abort the        balance of the transmission and retry again.    -   Bit 5—Ready To Transmit (RTT) 202C preferably indicates, if set,        that the IOCB 200 has data to send. When set, this bit asserts        Interrupt Request 11 (IRQ11) on the SBC 1. Once the interrupt        has been serviced and the character has been read, the IOCB 200        notifies its PSP hardware 201, 202 and resets this bit. The IOCB        200 then generates a Transmit Data Register Empty interrupt,        signalling that another character may be sent.    -   Bit 4—Transmit Abort (TA) 202D preferably indicates, if set,        that the IOCB 200 has detected an internal transmission error        while transmitting a packet to the SBC 1 and that no more data        will be sent. If the SBC 1 detects that this bit is set, it will        clear any previous characters received and abort the receive        process.    -   Bit 3—Busy 202E preferably indicates, if set, that the IOCB 200        is busy processing a critical application and prevents the SBC 1        from an erroneous time-out on a data transfer. The IOCB 200 sets        this bit upon entering a critical application, resetting it upon        completion. The SBC 1 will initiate a longer time-out interval,        but upon expiration, will report an error locking up the game.    -   Bit 2—0 202F This bit is reserved for future use.    -   Bit 1—Connect 202G preferably indicates, if set, that the        handshaking flags of this register should be ignored. The IOCB        200 sets this bit to the value 1 (indicating high impedance) if        the IOCB 200 and SBC 1 are disconnected, as the tri-state inputs        of the PSP hardware will be high, The IOCB 200 sets this bit to        the value 0 if the IOCB 200 and SBC 1 are connected These        tri-state inputs (high, low, high-impedance) prevent        interference between multiple devices attempting to access the        line and allow the IOCB 200 to act as a traffic controller. The        IOCB 200 always resets the bit to prevent erroneous actions        based on bit levels being set.    -   Bit 0—Reset 202H preferably indicates to the SBC 1, if set, that        the IOCB 200 has been up or reset, alerting the SBC 1 to set the        ‘state’ of the gaming devices in the machine. That bit is reset        each time initial communications are established between the        IOCB 200 and the SBC 1.

FIG. 3 depicts the interconnections among the IOCB 200 and five devices3 in the preferred I²C multi-drop configuration 250. The IOCB's I²C port203 is connected to each Device Board 4 through preferably a four-wiremulti-drop bus 250. The preferred I²C capable multi-drop bus 203 haspreferably four wires (clock 251, data 252, Logic Power 253 and SystemGround 254) which are distributed through the machine, providing theDevice Boards 4 with a means to utilise the clock, data, power and aground of the IOCB 200. Each device 3 is equipped with a Microprocessorbased electronic circuit board 4 (the “Device Board”) which isspecifically designed to interface with the device's input or outputsignals depending on the device. The Device Boards 4 are capable ofcommunicating using network-capable communications protocols, preferablyInter-Integrated Circuit (I²C) protocols, enabling interconnection amongthe devices 3. In the preferred I²C multi-drop bus 250, clock 251, data252, Logic Power 253 and System Ground 254 are distributed in eachdevice providing a clock, data transmission, power and ground to theDevice Boards 4. A Device Board 4 can be attached to more than oneDevice 3. In that event, more than one device will have a singlecommunications protocol address (preferably an I²C address), but eachdevice will have a unique Virtual ID.

FIG. 4 depicts data transfers of SBC-initiated transmissions between thedevices 3 and the SBC 1 through the IOCB 200. Data transfers between theIOCB 200 and the SBC 1 are based on a PSP framed packet 500 with thepreferably following protocol:

[Virtual ID][size][sequence #][Command][ . . . body . . . ][ETX][CRC-16]

-   -   Virtual ID 500A: this byte preferably contains a circuit number        or reference number by the SBC 1 determines which        device-specific software driver is used to interpret a message        received from the device 3 or to generate the particular data        sent to the device 3.    -   Size 500B: this byte preferably contains the character length of        the PSP framed packet from Virtual ID 500A to the CRC-16 500G        inclusive.    -   Sequence 500C: this byte preferably contains the message        sender's next sequential number. The message receiver maintains        an expected sequential reception number corresponding to the        message sender's Virtual ID. This sequence number is initiated        to a 0 value and is incremented by 1 for each successful        transmission, wrapping at the value of 255 back to a value of 1.        The value of 0 is only used on initial setup, and if the value        is 0, the message receiver resets its expected sequence number.        The sequence number provides additional security to ensure that        all transmissions are received (see FIG. 6). If the message        receiver has accepted the valid transaction (all packet criteria        has been satisfied), this constitutes a successful transmission        and the message receiver responds to the message sender by        transmitting an acknowledge (ACK) packet which will cause the        message sender and receiver to increment their sequence numbers.    -   Command 500D: this byte preferably informs the message receiver        what to do with the (if any) in the body of the message. For        example, if this bytes contains “ACK”, this acknowledges the        message sender's last received packet and contain 0 bytes in the        body of the message. Similarly, the IOCB 200 sends a Link        Request command (with 0 bytes) to the SBC 1 on power-up, which        requests a communication link. In an additional example, a Bill        Acceptor transaction with a command of ‘B’ signifies that the        Bill Denomination is in the message body and contains four bytes        in the body of the message. “ACK” has the hexadecimal value of        06, indicating a positive acknowledgment. “NAK” has the        hexadecimal value of 15, indicating a negative acknowledgment.    -   Body 500E: this byte preferably contains a variable number of        bytes from 0 to 248, contains pertinent data regarding the        transaction. For example, this field may contain the        denomination of the bill accepted, the coin denomination, or the        Player's Account Number processed by the Magnetic Card Reader.        The actual specific data contained are determined by the Virtual        ID involved.    -   ETX 500F: this End of Transmission (ETX) byte is preferably used        for packet. ETX has a hexadecimal value of 04, signalling End of        the Transmission.    -   CRC-16 500G: this two-byte field preferably is a 16-bit Cyclic        Redundancy Check (CRC) value, used for packet validation and        security. The CRC-16 value is generated using a 16-bit reverse        polynomial-based algorithm performed on each        transmitted/received byte. This 16-bit value is initially set to        0 and each byte of each Device Board 4 and the device type byte        (Coin Mechanism, Bill Acceptor, etc.) is cyclic redundancy        checked (CRC'd). The resultant 16-bit value, called the ‘seed’,        is used as the initial value prior to applying the CRC algorithm        to each byte in the packet. A CRC value is generated for each        packet and includes the entire packet, from Virtual ID to ETX        inclusive. A packet's CRC value is compared to the device's 3        seed and should be equivalent if the packet has been        successfully transmitted. The CRC-16 ‘seeding’ is applied to all        transactions except the ‘R’egister Command, which is used when a        device 3 is being registered for inclusion in the device table        (see FIG. 7). With the Register command, the receiver does not        have any knowledge of the Board ID or the type of device        registering in the communication packet, the seed is assumed to        be 0. In the examples, the CRC-16 value of ‘O×CCCC’ is used for        reference only. The actual 16-bit value would vary depending on        the data bytes in the packet.

Communication packets transferred between the SBC 1 and the IOCB 200(PSP framed packets 500) preferably have a Virtual ID 500A embedded inthe packet which is used to steer the transaction to the appropriatesoftware driver of the appropriate device. Communication packetstransferred between the IOCB 200 and the device 3 (preferably I²C framedpackets 520) preferably use an I²C address 520A to steer thetransaction. The IOCB 200 directs transactions both between the IOCB 200and the SBC 1 and between the IOCB 200 and the devices 3. Due to itsdual function, the IOCB 200 must wrap 524, 525,526, 527 theSBC-generated PSP packet 500 with preferably I²C framing 520 prior tosending 528 the packet to a device. Likewise, it must unwrap (FIG. 5,616) the preferably I²C frame 520 from the device generated PSP packet500 prior to sending the packet to the SBC 1.

Each Device Board 4 may have more than one physical device attached toit. For example, a Device Board 4 may be attached to two hoppers, one todispense coins, the other to dispense tokens. As a Device Board 4 hasonly one communications protocol address, preferably the I²C address520A, but two Virtual IDs 500A, the IOCB 200 checks 552 its device table552 for two table entries with the 1 same I²C address 520A. Utilisingboth the PSP and the I²C framed protocols, the IOCB 200 directs 528 bothSBC 1 generated commands (in our example, ‘C’ & ‘T’) to the same I²Caddress 520A. The Device 3 at that I²C address 520A will unwrap 544 theI²C framing bytes and act on 546, 548 the PSP Virtual ID's Command byte500D and message body 500E.

The following example further illustrates the process by which the IOCB200 wraps a PSP framed packet 500. The SBC 1 wants to turn on Deck Lamp#4 with the device's Virtual ID of 126, the sender's next sequentialtransmission number of 56, and the command byte of ‘L’. Using thefollowing PSP packet format 500 and values:

[Virtual [size] [sequence [Command] [body] [ETX] [CRC-16] ID] #] [126][8] [56] [L] [0x04] [ETX] [0xCCCC]

The PSP packet 500 will contain the above listed data. Assuming thereare no communication errors and the packet criteria is acceptable (seeFIG. 6), the IOCB 200 references its device table 554, finds thisVirtual ID value 126 at I²C address value 32. By these values, the IOCB200 determines 551 that the data packet 500 initiated from the SBC 1,determines 553 that the received data packet is not intended for theIOCB 200 and thereby ignores 555 the sequence number 500C, the Command500D and the body 500E of this packet. The IOCB 200 uses the size byte500B only to count down the received bytes, i.e. mark the end of thepacket 557.

The IOCB 200 then wraps this packet with its own I²C frame. The IOCB 200first creates 525 the message body 520 E of an I2C packet 520 from thePSP packet 500. The IOCB 200 assigns the value of “M” 526 to the Commandbyte 520D in the I²C packet 520 signifying that the SBC 1 originatedthis transaction. The IOCB 200 then assigns 527 the next availablesequential transmission number from the IOCB 200 to the sequence number520C for this I²C address 520A. The I²C packet 520 is assigned the I²Caddress 520A of 32 (524). In the example, the I²C packet is populated asfollows:

[I²C Address] [size] [sequence #] [Command] [ . . . body . . . ] [ETX][CRC-16] [32] [15] [143] [M] [PSP pkt] [ETX] [0xCCCC]

The IOCB 200 then sends 528 the I²C packet 520 to the device 3. Assumingthere are no communication errors and the packet criteria is acceptable536, 538, the device 3 sends an I²C framed packet 520 to the IOCB 200acknowledging (ACK) its transmission 532. Upon receiving theacknowledgment 560, the IOCB 200 creates and sends 560 a PSP-framedpacket 500 to the SBC 1 acknowledging the Virtual ID has accepted itstransaction.

If the I²C Command byte 520D of ‘M’ indicates the SBC 1 originated thistransaction 542, as opposed to the IOCB 200, the I²C body 500F containsthe PSP packet 500 sent by the SBC 1. The device 3 at this I²C addressunwraps the I²C framing bytes 544, reads 546 the PSP framed packetCommand (‘L’ in our example) and acts on 548 the Command by turning onLamp #4.

FIG. 5 depicts data transfers for device-initiated transmissions amongthe devices 3 and the SBC 1 through the IOCB 200. The communicationsprotocol framed packet, preferably the I²C framed packet 520, istransferred between the IOCB 200 and the device 3. Each preferred I²Cframed packet is comprised of the following parameters.

-   -   I²C Address 520A—Range 9 to 76 h,        -   —0 reserved for Broadcast Address,        -   —1–7 reserved for I²C implementation,        -   —8 reserved for the IOCB Address,        -   —77 h reserved for unregistered devices.    -   Header 520B, 520C, 520D—Packet Size, Sequence Number, Command        (each one byte).        -   The “ACK” value for Command has a hexadecimal value of 06,            indicating a successful transmission, and the “NAK” value            for Command has a hexadecimal value of 15, indicating an            unsuccessful transmission.    -   Body 520E—Up to 248 bytes of binary data.    -   Footer 520F, 520G—ETX, CRC-16 (2 byte Cyclic Redundancy Check).

For example, a Device Board 4 has three devices 3 attached to it: Deckbuttons, Deck lamps, and a Coin-in Mechanism. Each of these devices 3 isassigned its own Virtual ID 500A but the Device Board 4 only possessesone I²C address 520A. In the example, the Coin-in Mechanism's Virtual IDis 41, the Deck button's Virtual ID is 14, and the Deck lamp's VirtualID is 126. The I²C address 520A is 39

Assume a coin has been inserted in the gaming machine. The Device Board4 detects this Coin-in action and, using the Coin-In Mechanism's VirtualID 500A of 41, sequence number 500C of 214, Command 500D of T, and thecoin value 500E of 25 (hex 19), the device 3 generates 572, 574. 576,578 the following PSP packet 500 with the following values:

[Virtual ID] [size] [sequence #] [Command] [ . . . body . . . ] [ETX][CRC-16] [41] [9] [214] [,I,] [0x0019] [ETX] [0xCCCC]

The PSP packet 500 is intended for the SBC 1, and, accordingly, the PSPPacket 500 must be encapsulated within an I²C packet for delivery to theIOCB 200 to be delivered to the SBC 1. The PSP packet 500 becomes thebody 520E of the I²C packet 520 (586), for which the additionalfollowing value are assigned 586, 588, 590, 592, 594, 596 to the I²Cpacket 520: the IOCB's hard-coded I²C address 520A of 8, a sequencenumber 520 C of 79, an I²C Command 520D of ‘D’ signifying “Device”originated, creating the following I²C packet 520:

[I²C Address] [size] [sequence #] [Command] [ . . . body . . . ] [ETX][CRC-16] [8] [16] [79] [D] [PSP pkt] [ETX] [0xCCCC]

The device 3 waits 610 until the next poll received from the IOCB 200and then sends 612 the I²C packet 520 to the IOCB 200. Once the IOCB 200receives the packet, it checks the “command” byte 520D of the I²C packetand, if “Command” equals “D” (for device) 614, the IOCB 200 strips 616the I²C framing characters. The IOCB 200 then sends 618 the PSP packet500, extracted from the body 520E of the I²C packet 520, to the SBC 1as:

[Virtual ID] [size] [sequence #] [Command] [ . . . body . . . ] [ETX][CRC-16] [41] [9] [214] [I] [0x0019] [ETX] [0xCCCC]

This PSP packet 500 is the original packet generated by the Device 3(see 572, 574, 576, 578, 580,582, 584). The SBC 1, upon receiving acoin-in transaction, checks if there are any communication errors 622and if the packet criteria is acceptable 620 (see FIG. 6). If the packetis okay, the SBC 1 takes appropriate internal action. If the packet hasbeen validly transmitted, the SBC 1 also sends an ACK transaction to theDevice 3. First, the SBC 1 generates 624 the following PSP framed packet500, assigning “Command” 520D the value of “ACK” 626, assigning othervalues 528, and sends 633 it to the IOCB 200 as:

[Virtual ID] [size] [sequence #] [Command] [ . . . body . . . ] [ETX][CRC-16] [41] [7] [214] [ACK] [0 bytes] [ETX] [0xCCCC]

Once again, the IOCB 200 encapsulates 634 this PSP packet 500 with itsI²C framing characters, looks up the I²C address 520A associated withthe Virtual ID 638, assigns the I²C address 640, assigns the value of“M” to “Command” 520D, creating the following I²C packet 520. The IOCB200 then sends this I²C packet 520 to the I²C address 520A found in itsdevice table for this Virtual ID 500A:

[I²C Address] [size] [sequence #] [Command] [ . . . body . . . ] [ETX][CRC-16] [39] [14] [79] [‘M’] [PSP pkt] [ETX] [0xCCCC]

Once the Device Board 4 detects the transmission 644 and ascertains thatit was sent from the SBC 1 646, the Device Board 4 at the I²C address520A strips 648 the I²C framing characters and decodes 650 the PSPpacket 500 embedded in the body 520E the I²C packet 520. The ACK Commandconfirms 652 to the Device 3 that the transaction was accepted by theSBC 1.

If appropriate, the SBC 1 generates another transaction 621 to be sentto the Device 3 responsible for updating the hard meter associated withthis coin-in transaction.

FIG. 6 depicts the preferred security devices of the invention whichensure the validity of the data transmissions. Each time a device 3 orthe SBC 1 sends a transmission, upon receipt 670 of the packet, thereceiving module (the Receiver) checks the I²C packet 520 received toensure validity of the received packet. First, the Receiver counts thenumber of characters received 672 and compares 674 this value to the“size” field of the received packet. If the packet passes this test, theReceiver then checks 676 if the “sequence number” of the received packetequals the receiver's next expected sequence number. If the packetpasses this test, the Receiver checks if the ETX code is detected 678 atthe correct index in the packet. Lastly, the Receiver calculates 680 theCRC-16 value of the received packet and checks 682 if the 16-bit CRCvalue received is equal to the calculated 16-bit CRC. If any of thesetests fails, this indicates a communication failure and the Receivercreates a NAK packet 684, assigning “Command” a value of “NAK” 686,assigning the other values 688, and wraps 690 the PSP packet to notifythe sender that the transmission failed. Upon receipt of the NAK packet,the sender reconstructs the packet and sends it again. If the receiverdetects 698 more than three consecutive attempts which result infailure, the appropriate steps of error notification 700 are taken.

Should a transmitted packet fail any validation check, the receiver willsend a Negative Acknowledge (NAK) packet 684, 686, 688 to the senderindicating an error. The sender will retry up to three times 698 beforedeclaring a communication failure 700 causing the sender to re-enter theinitialisation state 702 and attempt to re-establish a communicationlink (see FIG. 6).

FIG. 7 depicts the preferred device registration by the IOCB 200 of eachdevice. Upon power up 710 or reset 702, the IOCB 200 assigns 712 thesame default physical I²C address 520A (77 h) to each device 3. Ifregistration of the device is not necessary, the IOCB 200 allocates 705bus time for each device 3 to register. The IOCB 200 then dynamicallyassigns an I²C address 707 which is clocked out to the responding slavedevice. The IOCB 200 sets up 709 a table 554 corresponding to thisaddress and populates 709 the table with the data it has received fromthis slave device. A Virtual ID 711 is assigned to this device 3 whichthe SBC 1 will use to invoke a software driver pertaining to this device3. The IOCB 200 creates 713 a PSP packet 500 (Virtual ID, a ‘R’ egisterCommand, and the device particulars 715, 717) and sends 719 the PSPPacket 500 to the SBC 1. The SBC 1 checks 729 if this device is on file727, creates an ACKnowledging PSP Packet 733 with the value of “ACK” forthe “Command” 735, checks if the device 3 needs configuration 736, addsconfiguration parameters to the “Body” of the packet 738, and sends 743a Register ACKnowledge command to the IOCB 200 confirming this device isvalid and commits the tabled entry as valid 737. Upon receipt of theacknowledgment 745, the IOCB 200 adds 747 this I²C address 520A to itspolling list 554. If this particular device 3 needs configuring 736, theSBC 1 embeds 738 the configuration parameters into the message body 500Eof the Register ACKnowledge packet sent to the IOCB. The IOCB 200resends 755 these parameters in the I²C packet sent to the device 3.

If the SBC 1 has no information on this device 731, or this device 3 isnot allowed in this machine 731, a Register NAK command is created 739,741, and sent 743 to the IOCB 200 signifying registration denial of thisdevice. Upon receiving a “NAK” packet 749, the IOCB 200 re-sends 755 theRegister NAK command to the device and removes 751 the device's I²Caddress 520A in the table list of devices. The Device Board 4re-initialises 702, re-configures its address as 77 h 712, and attemptsto register 705. If after three attempts to register has failed 740, theSBC 1 displays an error message 742.

On initial power-up (FIG. 7, 702, 710) or reset, each Device Board 4 isprogrammed as default I²C address 77 h (see FIG. 7) and, upon successfulregistration, the device's I²C address is added to the poll list 747.The IOCB 200, periodically polls I²C address 77 h for any response byfollowing I²C standard protocols. The protocol mandates the IOCB 200check if any device other than the IOCB 200 is asserting a clock 771. Ifnot, the IOCB 200 sets the clock 773, raises the clock line 777, and,with the data line 252 high, lowers 775 the clock line 251 (startcondition) thereby alerting all I²C devices 3 on the bus (Slaves), thatthe IOCB 200 (Master) is sending an address byte. During registration,the IOCB 200 creates 783, 785, 787 and sends 791 an I²C packet onto thedata line. This packet has the address 77 h “clocked out” on the dataline, i.e., the first seven bits of the I²C address have a value of 77 hand the eighth bit signifies either the IOCB's intent to read a bytefrom this address or write a byte to this address.

The IOCB 200 expects an Acknowledge on the data line 719 (low condition)from a device 3 at this address. The Master will provide 831 the ninthclock for the expected ACK condition. Any devices 3 which do not haveI²C address 77 h ignore 853 this prompt condition 791, 793. If a deviceor devices 3 are at this address 795 (there may be several devices withthe default value 77 h on initial power-up), the device 3 asserts 797,801 the data line low at the appropriate time to respond to the IOCB200. If the poll is intended for device registration (it is on initialpoll), the Master sets the Read flag 785, 787 intending to read theresponding device's registering data.

The I²C protocol mandates a stop condition 833 (a terminating conditionfor ² each I C transmission) which the Master (IOCB 200 or SBC 1) willprovide. Under I²C mode, the Master of the I²C line always provides theclock signal 773, even if a Read condition has been established and thuswill read 829 the data as it provides the clock 773 by which the Slavesends the data.

If multiple devices respond 803 to the IOCB's 77 h address byte, busarbitration will come into play. As the IOCB provides each clock pulse773, the devices will assert 811 their particular data bit onto the dataline, but each device will first sample 807, 809 the data line to ensureits level is its intended level. If the level is not at the intendedlevel, the particular device resets its I²C commitment 813 753, andbacks out of additional involvement 813 until it receives 815 the nextaddress byte from the IOCB 200. As arbitration may continue for severalbytes, the surviving device 3 will have finally completed itsregistration packet to the IOCB 200.

The IOCB maintains the device table 554 in preferably the followingformat:

-   -   Address—Dynamically assigned I²C address.    -   Device Type—Type of device (i.e. Coin mech., Bill acceptor,).    -   Sub-Type—Specific Make or Model.    -   Serial #—Unique Board Identification Number (Board ID).    -   Status—Last reported status.    -   Priority—Polling priority.    -   Virtual ID—SBC's end to end reference #.

As the IOCB 200 is continuously polling, the following example willdetail a typical poll transaction to the device at I²C address 39. Thepoll Command 520D ‘Q’uery will have 0 bytes in the message body. TheIOCB's next sequential transmission number 520C is 79 (the device 3 atthis I²C 520A address will be expecting this sequence number to be 79).The IOCB's I²C address 520A is hardcoded at 8.

[I²C Address] [size] [sequenced] [Command] [body] [EXT] [CRC-16] [39][7] [79] [‘Q’] [O bytes] [EXT] [0xCCCC]

The IOCB 200, as Master of the I²C bus, will clock out these data bytesto the Device Board 4 at this I²C address 520A. The Write flag is set789 in the packet's address byte 520A indicating the IOCB 200 is sendingdata. The device 3 ACKnowledges each byte by asserting 799, 801 the dataline at the ACK clock bit time frame. When the IOCB 200 has sent allbytes 819, the Read flag is set 821 in the address byte, and the IOCB200 re-sends 791 this byte. The IOCB 200, now expecting to receive data,will provide the clock to the Slave, but reads each clocked data linepulse 829 for 1 or 0, capturing 8-bits per byte.

[I²C Address] [size] [sequenced #] [Command] [body] [EXT] [CRC-16] [8][7] [79] [ACK] [0 bytes] [EXT] [0xCCCC]

In this read mode, the Master must assert the ACK pulse 831 after each8-bits 827 to tell the Slave that the Master has received this byte.When the Master has received a number of bytes equal to “size” 823, itdoes not assert the ACK pulse and generates the stop condition 833signifying the transfer has completed. The IOCB 200 receiving an ACKCommand 825 to the polling Query, states the device is active but has noinformation to send.

As the IOCB 200 is the only Master on the I²C bus 250, the IOCB 200detects 771 the clockline asserted by any other device attempting tocontrol the bus 250 during the polling process. After a small time-out835 in the event there is a possible spike or glitch on the bus, theIOCB 200 retests and, if this condition still exists, the IOCB 200asserts the clock line low 839 disrupting and prevents any further I²Ccommunications on the bus 250. The IOCB 200 also reports this condition841 to the SBC 1 for error reporting. After the shut down, the IOCB 200periodically releases the clock line 843 and retests 845 for the aboveviolation. If a retest shows the clock line is clear 847, the IOCB 200broadcasts ReRegister Commands 849 to all I²C devices 3 listed in thedevice table, requiring each to reset and reregister. The IOCB 200 alsoreports 851 the cleared condition to the SBC 1.

Due to the inherent security built in the preferred I²C protocol, andthe internal security checks designed into the IOCB 200 and SBC 1, asdescribed above, it is virtually impossible for an alien device toinvade the bus, or for a device to attempt communications with anotherdevice without the IOCB's knowledge and subsequent intervention.

It will be appreciated by persons skilled in the art that numerousvariations and/or modifications may be made to the invention as shown inthe specific embodiments without departing from the spirit or scope ofthe invention as broadly described. The present embodiments are,therefore, to be considered in all respects as illustrative and notrestrictive.

1. A method of creating a secured inter-processor and virtual devicedigital communications system capable of connecting at least one ofprocessors and virtually identified devices in a gaming machinecomprising the steps of: digitally and centrally storing and processingdigital information in a digital storage and central processing unit;bidirectionally connecting the digital storage and central processingunit and an input/output connection board; digitally storing andprocessing digital information in the input/output controller board;providing at least one connectable device; providing a centralprocessing unit for each connectable device; and bidirectionallyconnecting the at least one connectable device to the input/outputcontroller board using a communications-protocol capable ofcommunicating with the at least one connected device.
 2. The method ofclaim 1 further including the steps of providing a communicationsprotocol capable of communicating with multiple connectable devices; andproviding a Plug-N-Play communications protocol.
 3. The method ofcreating a secured inter-processor and virtual device communicationssystem as claimed in claim 2, wherein the step of providing at least oneconnectable device further comprises the step of providing gamingmachine devices.
 4. The method of creating a secured inter-processor andvirtual device communications system as claimed in claim 2, wherein thestep of providing a central processing unit for each connectable devicefurther comprises the step of connecting each central processing unit toat least one device.
 5. The method of creating a secured inter-processorand virtual device communications system of claim 1, wherein the step ofbi-directionally connecting the digital storage and central processingunit and the input/output controller board further comprises the step ofproviding an industry standard architecture (ISA) bus.
 6. The method ofcreating a secured inter-processor and virtual device communicationssystem of claim 5, wherein the step of providing an ISA bus furthercomprises the step of providing a PC-104 bus.
 7. The method of creatinga secured inter-processor and virtual device communications system asclaimed in claim 1, wherein the step of bi-directionally connecting thedigital storage and central processing unit and the input/outputconnection board further comprises providing an 8-bit bus.
 8. The methodof creating a secured inter-processor and virtual device communicationssystem as claimed in claim 1, wherein the step of bi-directionallyconnecting at least one device to the input/output controller boardfurther comprises providing an 8-bit register to connect at least onedevice to the input/output controller board in a multi-dropconfiguration.
 9. The method of creating a secured inter-processor andvirtual device communications system of claim 8, wherein the step ofproviding an 8-bit register further comprises: indicating whether theInput/Output Controller Board is ready to receive data; indicatingwhether the Input/Output Controller Board has aborted the reception ofdata sent by the digital storage and central processing unit; indicatingwhether the Input/Output Controller Board is ready to send data to thedigital storage and central processing unit; indicating whether theInput/Output Controller Board has aborted the sending of data to thedigital storage and central processing unit; indicating whether theInput/Output Controller Board is busy processing a critical application;whether system handshaking bits should be ignored; and indicatingwhether the Input/Output Controller Board has been powered up or reset.10. The method of creating a secured inter-processor and virtual devicecommunications system as claimed in claim 1, wherein the step ofbi-directionally connecting at least one device to the input/outputcontroller board further comprises connecting at least one device to theinput/output controller board in a multi-drop configuration includingthe steps of: providing a clocking means; transferring data; groundingthe system; and powering the system.
 11. The method of creating asecured inter-processor and virtual device communications system ofclaim 10, wherein the step of providing a clocking means furthercomprises the step of including a wire in a bus connecting theInput/Output Controller Board with each device.
 12. The method ofcreating a secured inter-processor and virtual device communicationssystem of claim 10, wherein the step of transferring data furthercomprises the step of including a wire in a bus connecting theInput/Output Controller Board with each device.
 13. The method ofcreating a secured inter-processor and virtual device communicationssystem of claim 10, wherein the step of grounding the system furthercomprises the step of including a wire in a bus connecting theInput/Output Controller board with each device.
 14. The method ofcreating a secured inter-processor and virtual device communicationssystem of claim 10, wherein the step of powering the system furthercomprises the step of providing a wire in a bus connecting theInput/Output Controller Board with each device.
 15. The method ofcreating a secured inter-processor and virtual device communicationssystem as claimed in claim 1, wherein the step of bi-directionallyconnecting at least one device to the input/output controller boardfurther comprises the step of having a multi-drop and network-capablecommunications protocol.
 16. The method of creating a securedinter-processor and virtual device communications system of claim 15,wherein the step of having a network-capable communications protocolfurther comprises the step of having a Philips' Inter-Integrated Circuit(I²C) communications protocol.
 17. The method of creating a securedinter-processor and virtual device communications system as claimed inclaim 2, wherein the step of providing a Plug-N-Play communicationsprotocol further comprises the steps of: registering devices; routingcommunications; arbitrating communications; and transferring data. 18.The method of creating a secured inter-processor and virtual devicecommunications system of claim 17, wherein the step of providing aPlug-N-Play communications protocol further comprises the steps of:polling devices for status; and providing a communications securitymeans.
 19. The method of creating a secured inter-processor and virtualdevice communications system as claimed in claim 18, wherein the step ofregistering devices further comprises the steps of: determining a needfor registering a device; assigning a default communication protocoladdress to a device; allocating bits time to register the device;assigning a communication protocol address to a device; obtaininginformation about a device; assigning a virtual address to the device;updating device parameters stored in a digital device table;transmitting the registration information to the digital storage andcentral processing unit; checking if the device is already registered;acknowledging the validity of the device registration; configuring thedevice; adding the registered device to a polling list; and deleting theregistered device from the polling list.
 20. The secured inter-processorand virtual device communications system as claimed in claim 19, whereinthe step of updating device parameters stored in a digital device tablefurther comprises the steps of: adding new device addresses andinformation; device addresses and information; and modifying deviceaddresses and information.
 21. The method of creating a securedinter-processor and virtual device communications system as claimed inclaim 19, wherein the step of updating device parameters stored in adigital device table further comprises the steps of adding, deleting,and modifying the following information for each connected device: acommunications protocol address; a device type; a device make or model;a device central processing unit serial number; a last reported devicestatus; a device polling priority; and a device virtual address.
 22. Themethod of creating a secured inter-processor and virtual devicecommunications system as claimed in claim 18, wherein the step ofproviding a communications security means further comprises the stepsof: comparing the size of the data packet received with the size of thedata packet sent; comparing an expected sequential identification numberof the packet received with the sequential identification number of thedata packet sent; comparing the end of the data packet sent with a codeidentifying the location of the end of the data packet sent; creatingand comparing a unique identification number of the data packet sentwith a code identifying the unique identification number of the datapacket sent; and sending a confirmatory data packet to the sendingdevice.
 23. The method of creating a secured inter-processor and virtualdevice communications system of claim 22, wherein the step of comparingthe size of the data packet received with the size of the data packetsent further comprises the step of comparing the size of the data packetreceived with a code identifying the size of the data packet sent. 24.The method of creating a secured inter-processor and virtual devicecommunications system as claimed in claim 22, wherein the step ofcomparing an expected sequential identification number of the packetreceived with the sequential identification number of the data packetsent further comprises the step of comparing dual and matchingsequential counters for the sending device and the receiving device. 25.The method of creating a secured inter-processor and virtual devicecommunications system as claimed in claim 22, wherein the step ofcomparing the end of the data packet sent with a code identifying thelocation of the end of the data packet sent further comprises the stepsof locating the end of the data packet sent and comparing the locationwith a code contained in the data packet identifying the location of theend of the data packet received.
 26. The method of creating a securedinter-processor and virtual device communications system as claimed inclaim 22, wherein the step of creating and comparing a uniqueidentification number of the data packet sent with a code in the datapacket sent identifying the unique identification number of the datapacket sent further comprises the step of performing a cyclic redundancycheck algorithm.
 27. The method of creating a secured inter-processorand virtual device communications system of claim 26, wherein the stepof performing a cyclic redundancy check algorithm further comprises thestep of performing a 16-bit reverse polynomial-based algorithm on eachbyte sent and on each byte received in a data packet.
 28. The method ofcreating a secured inter-processor and virtual device communicationssystem as claimed in claim 17, wherein the step of routingcommunications further comprises the steps of: acknowledging a physicalconnection; communicating with the main digital storage and centralprocessing unit; assigning a data packet with a specific protocoladdress; assigning a data packet with a unique virtual address; findingcommunications protocol addresses; a means for finding virtualaddresses; finding device information; wrapping a data packet with acommunications protocol address; wrapping a data packet with informationon a device initiating the communication; wrapping a data packet withother information; unwrapping communications protocol address andinformation from a data packet; transferring data packets initiated bythe main digital storage and central processing unit; and transferringdata packets initiated by the device.
 29. The method of creating asecured inter-processor and virtual device communications system ofclaim 28, wherein the step of finding communications protocol addressesand finding device information further comprises the step of locatingvirtual addresses in a digital device table.
 30. The method of creatinga secured inter-processor and virtual device communications system ofclaim 28, wherein the step of finding virtual addresses and findingdevice information further comprises the step of locating communicationsprotocol addresses in a digital device table.
 31. The method of creatinga secured inter-processor and virtual device communications system ofclaim 28, wherein the step of wrapping a data packet with acommunications protocol address and the step of wrapping a data packetwith other information further comprises the steps of creating a virtualaddressed unwrapped data packet with the following values: an assignedvirtual address; a size of the unwrapped data packet; a next sequencenumber for the unwrapped data packet; a type of sender of the unwrappeddata packet; a device command embodied in the unwrapped data packet; ameans for identifying the last position of the unwrapped data packet;and a unique 16-bit number for the unwrapped data packet, and creating acommunications protocol addressed wrapped data packet with the followingvalues: a communications protocol address; a size of the wrapped datapacket; a next sequence number for the wrapped data packet; a type ofsender of the data packet; an entire unwrapped data packet; a lastposition of the wrapped data packet; and a unique 16-bit number for thewrapped data packet; and wherein the body of the wrapped data packetincludes the entire unwrapped data packet.
 32. The method of creating asecured inter-processor and virtual device communications system ofclaim 28, wherein the step of unwrapping communications protocol addressand information from a data packet further comprises the step ofextracting the body of the wrapped data packet from the communicationsprotocol wrapped data packet.
 33. The method of creating a securedinter-processor and virtual device communications system of claim 28,wherein the step of transferring of data packets initiated by the maindigital storage and central processing unit further comprises the stepsof: sending the unwrapped data packet to a Input/Output ControllerBoard; retrieving the communications protocol address of the receivingdevice; directing the unwrapped data packet to the input/outputcontroller board for transmission to the addressed device; determiningthe validity of the received wrapped data packet; reading the unwrappeddata packet; acting upon the instructions in the unwrapped data packet;and sending a confirmatory data packet to the sending device.
 34. Themethod of creating a secured inter-processor and virtual devicecommunications system as claimed in claim 33, wherein the step ofsending a confirmatory data packet to the sending device furthercomprises the steps of: creating a confirmatory unwrapped data packet;sending the confirmatory unwrapped data packet to the Input/OutputController Board; wrapping the confirmatory data packet with framingcharacters to create a wrapped data packet; sending the wrappedconfirmatory data packet to the sender; receiving the wrappedconfirmatory data packet; stripping the wrapped confirmatory datapacket; and reading the unwrapped confirmatory data packet.
 35. Themethod of creating a secured inter-processor and virtual devicecommunications system of claim 28, wherein the step of transferring ofdata packets initiated by devices further comprises the steps of:detecting an action of a device; sending the wrapped data packet to aInput/Output Controller Board; sending a confirmatory packet;determining the validity of the received unwrapped data packet; readingthe unwrapped data packet; and acting upon the instructions in theunwrapped data packet.
 36. The method of creating a securedinter-processor and virtual device communications system as claimed inclaim 17, wherein the stop of arbitrating communications furthercomprises the steps of: providing a clock pulse; enabling devices tosample a data line to ensure an intended level; enabling devices toassert data onto the data line at the intended level: enabling devicesto reset a protocol commitment; and enabling devices to wait to assertdata onto the data line until receipt of a signal.
 37. The method ofcreating a secured inter-processor and virtual device communicationssystem as claimed in claim 17, wherein the step of polling devices forstatus further comprises the steps of: providing a clock; ensuring thatthe clock is provided by only one source; indicating a poll to alldevices; preparing to receive data from devices; indicating receivestatus; indicating a unique device address to be polled; creating a datapacket containing a poll query; sending a data packet containing thepoll query; devices preparing to receive a polling data packet;determining whether the poll is directed to a device; determining thatthe device should respond to the poll; creating a responding data packetwith device information to the poll; a means of transferring aresponding data packet to the poll; determining the type of response tothe poll; determining the validity of the response data packet; updatingdevice parameters stored in a digital device table; and acknowledgingthe success of the poll.
 38. The method of creating a securedinter-processor and virtual device communications system as claimed inclaim 17, wherein the step of transferring data further comprises thesteps of: providing a communications protocol addressed wrapped datapacket; and providing a virtual device addressed unwrapped data packet.39. The method of creating a secured inter-processor and virtual devicecommunications system of claim 38, wherein the step of providing acommunications protocol addressed wrapped data packet further comprisesthe step of creating a data packet with the following values: acommunications protocol address; a size of the wrapped data packet; anext sequence number for the wrapped data packet; a type of sender ofthe data packet; an entire unwrapped data packet; a last position of thewrapped data packet; and a unique 16-bit number for the wrapped datapacket.
 40. The method of creating a secured inter-processor and virtualdevice communications system as claimed in claim 39, wherein the step ofcreating a communications protocol address further comprises the step ofproviding an Inter-Integrated Circuit (I²C) address.
 41. The method ofcreating a secured inter-processor and virtual device communicationssystem as claimed in claim 39, wherein the step of creating a unique16-bit number for the data packet further comprises the step of applyinga cyclic redundancy check algorithm.
 42. The method of creating asecured inter-processor and virtual device communications system asclaimed in claim 38, wherein the step of providing a virtual addressedunwrapped data packet further comprises the step of creating a datapacket with the following values: an assigned virtual address; a size ofthe unwrapped data packet; a next sequence number for the unwrapped datapacket; a type of sender of the unwrapped data packet; a device commandembodied in the unwrapped data packet; a means for identifying the lastposition of the unwrapped data packet; and a unique 16-bit number forthe unwrapped data packet.
 43. The method of creating a securedinter-processor and virtual device communications system as claimed inclaim 1, wherein the step of bidirectionally connecting at least onedevice to the input/output controller board further comprises using amulti-drop connection including a clocking means, a data transfer means,a system ground means, and a logic power means.